<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "hht://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
        <META http-equiv="Content-Type" content="text/html; charset=UTF-8">
        </META>
        <title>Editing the Context</title>
    </head>     
    <body>
        <a name="definition"></a> 
        <h3>What Exactly Is the Context?</h3>
        <p>
            In SILKin our main focus is to learn the kinship terminology for a particular culture or language. 
            A set of definitions for all the kin terms is called a 'Domain Theory' (a computer science term). In
            some cultures there are two sets of kin terms: terms of reference and terms of address. But there is
            only one population of people and families, only one set of mores for marriage and courtesy, etc. 
            We say that this culture is the Context of our effort while we focus on learning one or two
            sets of kin terms (reference and address). If there is only one set of kin terms in the culture you are 
            studying, you may think of the culture, the domain theory (kin term definitions), and the Context as
            interchangeable. The distinction is only important to SILKin's inner workings.
        </p>
        <p>
        	The Context for any SILKin project contains one or two domain theories, the people and families,
        	etc. Whenever you Save (or Save As) your work in a SILK file, you are saving the entire Context.
       </p>
        <a name="editor"></a> 
        <h3>The Context Editor</h3>
        <p>
            Most of your time will be spent building family tree charts and recording the kin terms that people
            use with one another. Periodically, you will ask SILKin for suggestions and will act on those suggestions:
            gathering disambiguating data, confirming or denying synonyms and umbrella terms, and accepting or 
            rejecting proposed definitions for kin terms in this Context (the 'domain theory' we are trying to learn). 
            None of this activity requires the Context Editor.             
        </p>
        <p>
        	But a few things can only be done in the Context Editor:
        	<ul>
        	<li>View the records of persons or families that were deleted in the chart.</li>
        	<li>Un-delete persons or families.</li>
        	<li>View, Edit or Create User Defined Properties.</li>
        	<li>Edit or annotate one of the Domain Theories for this context.</li>
        	<li>Make notes and commentary about this culture that will be retained in the SILK file.</li>
        	<li>In a future version of SILKin, you can view and edit the matrix of kin terms
        		for this Context as a two-dimensional table.</li>
        	</ul>
       </p>
 		<p>You can also do two things here that duplicate other screens: indicate whether polygamy is permitted
 		in this culture, and whether there are distinct terms of address.
 		</p>
        <a name="deleted-records"></a> 
        <h3>Deleted Records</h3>
        <p> When working on the Chart, you can <a href="Chart.html#del-ppl">delete a person or a family</a> with your mouse. 
            If the person/family deleted was the last one created (has the highest serial number), SILKin will
            remove all trace of it. But if you delete the person with serial number 17 when there are higher serial numbers
            in existence, SILKin will mark that person (#17) as 'deleted' and they will disappear from your chart. But
            their record will still exist in the database. You can view it in the Context Editor in the 'View/Edit
            Person' drop-down list.
        </p>
        <p> If you click on a person in the 'View/Edit Person' list, an editor window will open that allows you to
        edit their properties. <span style="font-style: italic">In general, you should NOT use this editor to change a person's
        properties. Use the chart window.</span> But this is the only way to view a deleted person, and also the only way to 
        un-delete a person. Clicking on the Un-Delete button will make the person visible and usable again. Because SILKin
        cannot put the un-deleted person in their former position in the chart (the chart may have changed), the un-deleted
        person will appear in the upper left corner of the chart. You can drag them to wherever you want them.
        </p>
        <p>Likewise, if you have deleted a Family (union) you can view it or undelete it from the 'View/Edit Family'
        list. With both Families and People, it is not necessary to un-delete -- you could simply make a fresh Person
        or Family to replace the deleted one and link them with the rest of your chart. One motivation to un-delete
        might be if you had extensive notes in the Comments field of the deleted item. 
		</p>
        <p><span style="font-weight: bold">BE CAREFUL.</span> Do not delete the person or family if you only need to 
        <a href="Chart.html#del-rel">delete a relationship</a>. The next time you Save (or Save As) your data, all the people 
        and unions you deleted will be erased from the SILK file. This action cannot be undone.
		</p>
		<a name="UDPs"></a> 
        <h3>User-Defined Properties</h3>
        <p>SILKin has a built-in understanding of many words used in kinship (e.g. 'son'). <a href="Start.html#predicate-list">The list </a>
           is quite extensive. But sometimes a unique or seldom-used concept may be part of the kinship system you are studying.
           To allow for this, SILKin provides User-Defined Properties (UDPs). The meaning of a UDP is whatever the User decides
           it is, and the name is chosen by the User. However,  <span style="font-style: italic">the name of any UDP must begin
           with an asterisk/star ('*') and contain only lowercase letters.</span> SILKin will treat any property/predicate as a UDP if and only if the lowercase name begins
           with the asterisk/star (the upper case symbol on the '8' key of most keyboards).            
		</p>
		<p>You may think of UDPs as either <span style="font-style: italic">properties</span> or <span style="font-style:
		 italic">predicates</span> because they serve as both. For example: if your context provides special honor to bald-headed
		 men, you might create a UDP named '*bald'. Baldness is a property of some persons (a rather nice one, don't you think?)
		 so you can think of the UDP as a property. But you can use *bald as a <a href="HornClause.html#rules">predicate</a>. 
		 The built-in predicate 'father' allows you to state that Alter is Ego's father. Likewise your UDP *bald can be used
		 to declare that Alter is bald; in this case you are using the UDP as a predicate. (There is a tutorial about predicates
		 and their role in Horn Clauses <a href="HornClause.html#tutorial">here</a>.)
		</p>
		<p>A typical use of UDPs would arise in a context that uses <span style="font-style: italic">clans</span> in the
		kinship system. Not every society that recognizes clans uses them in their kinship system. But in some systems, a
		person of the same gender and the same clan has a kin term (gloss: 'clan brother'). In that case, you would want
		to create a UDP named '*clan' (or any other name you like, so long as it follows the naming rules). You do this by clicking
		on the 'Add UDP' button of the Context Editor. This brings up the 'Create New UDP' screen.			
        </p>
        <p>After choosing a name for your UDP, you must decide what kind of value it will have. In the example above, a UDP
        named '*bald' probably describes a property that is either true or false. So in the drop-down menu of Data Types you
        would choose 'boolean' (the mathematical name for true/false variables). Or if the *clan property has values like 'bear',
        'turtle', or 'fish' then you would choose the Data Type 'string' (i.e. a string of letters and numbers). A UDP may also
        have a Data Type of 'person'; you might use this for a *owner UDP in a slave-holding society, or for
        <a href="NonGen.html#adoption">adoption</a>. UDPs can have numeric Data
        Types also: either 'integer' (whole numbers) or 'real number' (a decimal number, like 98.6).
        </p>
        <p>A UDP may have multiple values, or not. A UDP describing the relative(s) responsible for passing on cultural knowledge
        or values (*mentor) could have multiple persons as values for the UDP. But if clan membership is exclusive, then *clan
        would be restricted to a single value. (Once you establish a UDP's data type and restrictions, SILKin will enforce them.) There
        may be only certain values that are legal. For example, there may be only four clans in the context: bear, fish, turtle,
        and eagle. If you check the radio button 'Yes' for 'Restricted to Certain Values' SILKin will prompt you to type in the
        legal values, separated by commas.
        </p>
        <p>Sometimes there is a common value that applies to most people but not all. In that case you may check 'Yes' for the
        Default Value and type that value in the box. This value will then be entered automatically for every person created. You
        can edit the few values that are different from the default in a person's Detail Display panel. But to create a UDP in your
         Context -- or modify it -- you must always use the Context Editor. Finally, for numeric values you can enter minimum 
         and maximum values.
        </p>
        <p>When you have entered all the information about a new UDP, you click the 'Check for Errors' button. SILKin will 
        assure all your entries make sense, then give you a 'Save' button. When you click 'Save' a UDP will be created for
        every person in the context. If a default value was provided, that value will be inserted for everyone. Thereafter, a
        UDP drop-down box will appear in the Detail Display for every person. The value(s) of their UDP(s) can be viewed and 
        edited in the Detail Display. (Adoption UDPs have their values changed graphically.)
        </p>
        <a name="EditTheory"></a> 
        <h3>Editing a Domain Theory</h3>
        <p>SILKin's main focus is to learn one or two domain theories for your context. Ideally SILKin will periodically
           compare your genealogical data and related kin terms to other kinship systems in its Library and suggest
           definitions for your kin terms based on definitions it has seen in other contexts. But SILKin is just a software
           program; you may figure out the definition for a term before SILKin does. If so, you will want to manually add your 
           definition to the domain theory.
		</p>
		<p>SILKin may have suggested a definition that is accurate, so you've accepted it. But you would like to express
		   the definition differently. This requires editing an accepted definition. 
		</p>
		<p>Or you may have discovered a cultural
		   concept in your context that is not a kin term <span style="font-style: italic">per se</span> but the concept is
		   useful for expressing the definitions of kin terms. You would want to introduce an Auxiliary Term into the 
		   domain theory (a term that is not a kin term, but is used in the definitions of kin terms). For example: if your
		   context has terms for 'female cross cousin' and 'male cross cousin' it makes sense to first define the concept of
		   'cross cousin' (as it is understood locally) and then use that term in the definition of both the male and the
		   female kin term.
		</p>
		<p>To accomplish any of these things, you must click on 'Edit Theory'. This will take you to a separate screen for
		   that purpose. Because you need to understand the basics of Horn Clauses in order to edit a domain theory, there is a separate
		   <a href="HornClause.html">help page devoted to editing Horn Clauses</a>. That page explains how to edit a 
		   domain theory (set of definitions).
		</p>
    </body>
</html>
